Resolver context has a reference to the parent context as of #294.

type ResolverContext struct {
	Parent *ResolverContext
	// The name of the type this field belongs to
	Object string
	// These are the args after processing, they can be mutated in middleware to change what the resolver will get.
	Args map[string]interface{}
	// The raw field
	Field CollectedField

	// indicies tracks the array indicies only. all field aliases come from the context stack
	indicies []int
}

Perhaps this would be better represented by
graphql.GetResolverContext(ctx).Parent.Result
and would also allow for
graphql.GetResolverContext(ctx).Parent.Parent.Result

this PR collide with #302 🤔

This PR introduce Result field to ResolverContext. and I refactor ResolverContext that looks like immutable.

@vektah Result and ParentObject is not equals.
Resolver make []Todo, this is Result.
I think that Directive want a Todo, this is ParentObject.
so, I want to implement both. what do you think about this opinion?

I noticed that there are multiple ideas of ResolverContext...

1. Definition closely related to the current Resolver implementation.
2. Every time Path changes, a new child ResolverContext is created.

I think the 2 is more convenient.
For example, if we want to issue an error in Resolver for some Index in Resolver that returns Array, we need to be able to generate new child ResolverContext ourself.
Specifically, if an illegal id is passed to nodes (ids: [ID!]!): [Node]!.

Also, when users browse / create ResolverContext, it is not known where asynchronous processing will be occurred.
For this reason, I think that ResolverContext created once, it should be immutable.
So, I think it is complicated to use PushIndex and Pop, and I think it is dangerous.

It might be well refactored. 🤔

I still think its a bit weird to be creating a new resolver context for each result, currently all of that state stays on the stack as method args for normal resolvers. Perhaps this should work the same? see #314 for an alternative.